Einfluss erweiterter Programmier-Paradigmen auf die Entwicklung eingebetteter DBMS

Abbildung 1: OOP-Zugriffssystem OOP. Die Intention der OOP ist die Kapselung von Funktionen und Eigenschaften nach ihrer Zugehörigkeit zu RealweltObjekten in Klassen. Erweiterungen an Klassen können nicht-invasiv durch Überschreiben, Überladen und Hinzufügen von Methoden in Subklassen eingebracht werden. Diese erben die Funktionalität ihrer Oberklasse. In der Implementierung des Zugriffssystems (vgl. Abb. 1) erben die Klassen ”ODAS” und ”HDAS” (Zeilen 9-13) die Beschreibung der abstrakten Klasse ”DAS” (Zeilen 1-8) und implementieren die virtuellen Methoden ”remove” und ”insert” mittels Heap-Speicherung oder sortierter Speicherung. Durch das gemeinsam ererbte Interface ”DAS” sind die Varianten nun für den übrigen Quellcode transparent ansprechbar. Erweiterungen um neue Varianten der Zugriffsstrategie können in einer Klasse gekapselt hinzugefügt werden, z. B. hash-basierte Sortierung. Die Fixierung der Strukturen und Beziehungen von Klassen im Software-Design und Quellcode erfordert invasives Eingreifen bei evolutionären Änderungen. Das verursacht Code-Replikation und im Folgenden schlecht wartbare Software.2 Unerwartete Variationen innerhalb von MethodenImplementierungen der Superklasse ”DAS” wie Indexpflege oder Logging erfordern ebenfalls invasive Änderungen. Das modulare Hinzufügen dieser optionalen Funktionen erfordert virtuelle Hook-Methoden mit Default-Verhalten (Indexpflege: Zeile 8). Sie können in der Subklasse überschrieben werden. Viele OOP-Design-Pattern beruhen auf diesem Prinzip, um Variabilität und Erweiterbarkeit zu ermöglichen. Der durch virtuelle Methoden entstehende Overhead in Speicherverbrauch und Performance ist für eingebettete Systeme jedoch nicht akzeptabel [4, 9]. GP. Als eine aufbauende Technik führt GP die Unabhängigkeit der Klassen und Methoden von Typen ihrer Interaktionspartner mittels Templates ein. Die als variabel deklarierten Typen werden durch die erzeugende oder aufrufende Methode durch zusätzliche Parameter zur Übersetzungszeit konkretisiert in OOP ist diese Typisierung bereits im Design festzulegen [3]. Die Vorverarbeitung durch den Compiler macht ein einheitliches Interface mittels abstrakter Klassen unnötig. Diese Parameter ermöglichen ebenfalls eine Auswahl von Implementierungen. Das durch Templates implementierte Zugriffssystem in Abbildung 2 verwendet die eigens zur Parametrisierung eingeführten Klassen ”HDAS” und ”ODAS” (Zeilen 13 und 16), um die Implementierung der Methoden des Zugriffssystems auszuwählen. Die statische Auswahl der Implementierung (Zeile 18) ermöglicht Variabilität ohne virtuelle Methoden mit ihren Nachteilen bezüglich Speicherverbrauch und Performanz. Die Vorteile dieser statischen Bindung verursachen Schwierigkeiten an anderer Stelle. Erweiterungen um zusätzliche Varianten wie hash-basierter Zugriff oder eine Veränderung Bestehender ist in diesem Beispiel nur invasiv möglich Vererbung verSowohl die Klasse als auch ihre Subklassen müssen repliziert werden um Varianten zu erhalten. ursacht hier eine vollständige Redefinition. Die Parametrisierung im Quellcode verursacht erheblichen Pflegeaufwand bei Änderungen des Template-Interfaces. Die Reduzierung der Anforderungen an das Interface der Interaktionspartner auf die eigens verwendeten Methoden bietet eine lose Kopplung der Komponenten und Robustheit gegenüber neuen Typen. Im Gegenzug ist die semantische Prüfung auf Teilmengen-Relation nicht mehr möglich.3 1 template < class strat > class DAS{ 2 void modify(Tuple* old , Tuple* newT){ 3 TID tid = remove(old); 4 insert(newT , tid); 5 modInd(newT , tid); } 6 TID insert(Tuple* t){...} 7 void insert(Tuple* t, TID place ){...} 8 ... 9 TID hookIns(Tuple* t); 10 void modInd(Tuple* t, TID newTID ); }; 11 template < class strat > 12 void DAS :: modInd(Tuple* t, TID tid ){...} 13 class ODAS {}; // ordered DAS 14 template <>TID DAS :: hookIns(Tuple* newT ){...} 15 template <>TID DAS :: lookup(Tuple* t){...} 16 class HDAS {}; //heap−access 17 ... 18 DAS _DASInstance; Abbildung 2: Zugriffssystem mit GP AOP. AOP ermöglicht eine zusätzliche Modularisierung von System-Eigenschaften. OOP ermöglicht die Komposition der Komponenten nach der TeilmengenBeziehung. Dies verursacht CodeReplikation anderer gleicher Eigenschaften der Komponenten an verschiedenen Stellen des Programms. Der Code dieser sog. ”querschneidende Belange” hat zudem keine semantische Beziehung zur ihn allokierenden Klasse [6]. Durch die erweiterte Separierung der Belange werden Wartbarkeit und Verständlichkeit erhöht [3]. Der in sog. Aspekten gekapselte Code (sog. Advice) wird um Beschreibungen seiner Wirkungspunkte im Programm (sog. Pointcut) erweitert. Den Aufruf des Advice am Pointcut initiiert ein Weber [6]. Eine Vorbereitung der Komponenten auf Variabilität und Erweiterungen ist somit nicht notwendig. Variabilität wird durch Auswahl der anzuwendenden Aspekte ”ODAS” bzw. ”HDAS” erreicht (nicht dargestellt). Die Aspekte kapseln die variablen Implementierungen der Methoden ”hookIns” und ”lookup”. Die zu erweiternde Klasse ”DAS” bildet den Join-Point. Nicht benötigter Code wird nicht gewebt und benötigt keinen Speicherplatz im übersetzten System. Modulare Erweiterungen sind durch das Hinzufügen weiterer Aspekte möglich. Aspekte ermöglichen die Manipulation der Klassenhierarchien der Komponenten bis zur Endphase der Software-Entwicklung (Compilation der Software) in OOP und GP sind diese Design-Entscheidungen zum Beginn der Software-Entwicklung zu treffen. So können variable Eigenschaften des Systems spät konfiguriert werden. Das vermeidet die Neu-Entwicklungen speziell angepasster Software. Das inkrementelle Erweitern von Aspekten gestaltet sich hingegen schwierig durch die Notwendigkeit des vollständigen Wissen über die Wirkungsweise der erweiterten Aspekte. 1 // l ay e r base 2 class DAS{ 3 void modify(Tuple* old , Tuple* newT){ 4 TID tid = remove(old); 5 insert(newT); }}}; 6 // l ay e r ODAS 7 refines class DAS{ 8 TID lookup(Tuple* t){...} 9 TID remove(Tuple* t){...} 10 TID hookIns(Tuple* newT ){...}}; Abbildung 3: Zugriffssystem FOP FOP. Die FOP verbessert die Erweiterbarkeit von Software durch inkrementelle Verfeinerungen (sog. ”stepwise refinement”) [2]. Die eine abstrakte Eigenschaft betreffenden Code-Fragmente und Klassen werden in Schichten gekapselt. Das ausführbare Produkt ist nach Batory eine Konstante, hier ”base” (Abb. 3, Zeile 1), auf die sukzessive Erweiterungen angewendet werden [2]. Die Erweiterungen am Beispiel des Zugriffssystems sind ”ODAS” (Zeile 6) bzw. ”HDAS”. Durch eine Zusammenstellung der Schichten kann statische Variabilität der Klassen erreicht werden [2]. Die Klasse ”DAS” setzt sich aus den Fragmenten der Schichten ”base” und ”ODAS” (Zeile 6) bzw. ”HDAS” zusammen. Durch Austausch der Layer ist eine unabhängige Variation des AlgoIm Gegensatz zu C++ bieten Eiffel und Ada diese Funktionalität sog. ”constrained genericity” [3]. rithmus (Zeilen 3-5) und der Implementierungen seiner Schritte (Zeilen 8-10) möglich. Mixins als mögliche Umsetzung erlauben eine variable Zusammensetzung der Fragmente durch die Parametrisierung von Klassen mit ihren Superklassen. Vererbung ermöglicht diese Variation einzig durch virtuelle Methoden mit ihren inhärenten Problemen oder Code-Replikationen [4]. Die Variabilität der FOP erfordert keine virtuellen Methoden und ermöglicht eine additive, statische Anpassung an die konkreten Anforderungen des Produktes. Weiterhin können die statisch variablen Klassen einheitlich durch referenzierenden Code behandelt werden. Das neue Modul ist durch die Kapselung mehrerer Fragmente eine Kollaboration statt einer Klasse in OOP oder GP. Erweiterungen an bestehenden Klassen (sog. refinements) durch Member oder das Hinzufügen neuer Klassen ist durch das Anwenden weiterer Schichten möglich [2].